As used herein, the following abbreviations shall have the following meanings:
3GPP Third Generation Partnership Project
ACM Address Complete Message
BSS Base Station Subsystem
CAMEL Customized Applications for Mobile networks Enhanced Logic
CDMA Code Division Multiple Access
CS Circuit Switched
DTM/PSHO Dual Transfer Mode/Packet Switched Handover
EPS Evolved Packet System
E-UTRAN Evolved-UTRAN
FQDN Fully Qualified Domain Name
GAN Generic Access Network
GANC GAN Controller
GBR Guaranteed Bit Rate
GERAN GSM EDGE Radio Access Network
GSM Global System for Mobile Communications
GW Gateway
HLR Home Location Register
HO Handover
HSS Home Subscriber Server
IMS IP Multimedia Subsystem
IAM Initial Address Message
IMSI International Mobile Subscriber Identity
IP Internet Protocol
ISDN Integrated Services Digital Network
ISUP ISDN User Part
LTE Long Term Evolution
MGW Media Gateway
MM Mobility Management
MME Mobility Management Entity
MMTel Multimedia Telephony
MSC Mobile Switching Center
MSISDN Mobile Station International Subscriber Directory Number
Non-GBR Non-Guaranteed Bit Rate
O&M Operations and Maintenance
PS Packet Switched
QCI QoS Class Identifier
RAN Radio Access Network
SDP Session Description Protocol
SES Send End Signal
SGSN Serving GPRS Support Node
SRVCC Single Radio Voice Call Continuity
STN-SR Station Transfer Number for SRVCC
TAU Tracking Area Update
UE User equipment
UMTS Universal Mobile Telecommunications System
UNI User Network Interface
UTRAN UMTS Radio Access Network
VANC VoLGA Access Network Controller
VCC Voice Call Continuity
VoIP Voice over Internet Protocol
VoLGA Voice Over LTE via Generic Access
WCDMA Wideband CDMA
The 3rd Generation Partnership Project (3GPP) is a collaboration among groups of telecommunications associations, to make a globally applicable third generation (3G) mobile phone system specification within the scope of the International Mobile Telecommunications-2000 project of the International Telecommunication Union (ITU). 3GPP specifications are based on evolved Global System for Mobile Communications (GSM) specifications. 3GPP standardization encompasses Radio, Core Network and Service architecture. The project was established in December 1998.
The 3GPP Specification provides different methods to support a voice service via Evolved Packet System (EPS). One is Internet Protocol (IP) Multi-media Subsystem (IMS) Multimedia Telephony (MMTel) which may be required to use Single Radio Voice Call Continuity (SRVCC) if there are no Voice over Internet Protocol (VoIP) over Packet Switched (PS) radio bearers in the wide area network. SRVCC supports IMS Voice with a mechanism to move the GSM, Wideband Code Division Multiple Access (WCDMA) or cdma2000 1xRTT access and support voice service using a Circuit Switched (CS) bearer rather than a packet bearer which is the primary choice for an IMS based voice service.
Another method to support a voice service via EPS is CS fallback wherein the user has access to the voice service while being connected to the Long Term Evolution (LTE) access, but the voice service is provided by an access that has (native) support for a CS voice service, i.e. GSM, WCDMA, or cdma2000 1xRTT. Furthermore, there are industry initiatives to improve CS fallback by re-using some of the SRVCC mechanisms. However, re-using standardized methods provided by 3GPP may create conflicts among the different methods.
There are a number of disadvantages with each of these methods. The service level of IMS has not reached the level of functionality that is present in the CS network currently. CS fallback does not use LTE radio resources for the CS service, and requires longer call setup time than that of conventional CS networks.
To remedy these disadvantages, several methods of operating the CS service over LTE have been proposed. One of these methods re-uses Generic Access Network (GAN) architecture. GAN allows the CS services to be operated over a generic IP access and internet, e.g. provided over a WLAN. To support handover, the terminal is assumed to use two (2) radios, one for the macro network and one for the IP access network. Such is not the case when applied in LTE. In that situation, only one radio is assumed, as only one RAT can be used at one instance in time. To operate, as noted above, mechanisms from SRVCC are re-used.
A forum, Voice over LTE via Generic Access (VoLGA) has formed to specify how to make traditional GSM/Universal Mobile Telecommunications System (UMTS) CS services available to User Equipment (UE) accessing the EPS network via LTE. The VoLGA service resembles the 3GPP GAN. GAN provides a controller node, the GAN controller (GANC), inserted between the IP access network (i.e., the EPS) and the 3GPP core network. The GAN provides an overlay access between the terminal and the CS core without requiring specific enhancements or support in the network it traverses. This provides a terminal with a “virtual” connection to the core network. The terminal and network thus reuse most of the existing mechanisms, deployment and operational aspects of the network. GAN services and objectives are reused in VoLGA wherever beneficial.
For VoLGA, all signalling and user plane traffic is fully transparent to the EPS access network on the User Network Interface (UNI). This means that the EPS regards all VoLGA traffic as normal user plane traffic occurring over suitable EPS bearers. It also implies that the UE must attach to the EPS first before any VoLGA traffic can occur. VoLGA specific support may be added to the EPS if required to ensure a complete solution.
An important distinction between VoLGA services and GAN services exists. VoLGA only supports access to CS services, not PS services. Unlike GAN, VoLGA does not support packet access to the 2G/3G Serving GPRS Support Node (SGSN). Instead, PS services are provided to the VoLGA enabled UE by directly employing the EPS system without any additional entities or functions related to VoLGA, other than the capability for combined Handover (HO) of voice, FAX, data, etc., and non-voice packet bearers. There is no impact on the PS service delivery onto the EPS UE from VoLGA. FIG. 1 shows the proposed architecture 100 for VoLGA at present including the VoLGA Access Network Controller (VANC) 101 as further explained herein. As noted hereinbefore, there are disadvantages to re-using SRVCC mechanisms. HOs from LTE to 2G/3G for VoLGA based on using SRVCC procedures are described below. To accomplish this, the network must in some way handle coexistence as described elsewhere in the art and is outside the scope of this application. Once it is determined known that a HO is for VoLGA, the VANC 101 where the UE 102 is registered must be found. The VANC 101 that is conventionally selected is based on the Tracking Area ID and load balancing algorithms. Mobility Management Entity (MME) 103 only uses target cell identity to select a HO peer. The data present in the HO signaling is not helpful to any other peer, for example a Hand Over Selection Function (HOSF) to select the correct VANC 101.
To address this issue, a number of proposed contributions have been made in VoLGA forum. All of the contributions include methods to inform the MME to which VANC a potential HO should be targeted. A problem arises however as such methods affect the MME, and hence, the MME of 3GPP release 8 cannot be used.
To further explain the context of the invention, reference is made to FIG. 2, which is the SRVCC architecture for the Evolved UTRAN (E-UTRAN) to 3GPP UMTS Radio Access Network (UTRAN)/GSM EDGE Radio Access Network (GERAN) and FIG. 3 is a call flow diagram 300 for SRVCC from E-UTRAN to GERAN without Dual Transfer Mode/Packet Switched Handover (DTM/PSHO) support.
As seen in FIG. 3:
Step 301. Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to GERAN.
Step 302. Source E-UTRAN sends Handover Required (Target ID, Source to Target Transparent Container) message to the source MME. The E-UTRAN also indicates to the MME that this is an SRVCC handover operation.
Step 303. Based on the QoS Class Identifier (QCI) associated with the voice bearer (QCI 1) and the SRVCC handover indication, the source MME splits the voice bearer from the non voice bearers and initiates the PS-CS handover procedure for the voice bearer only towards Mobile Switching Center (MSC) Server.
Step 304. The MME sends a Forward Relocation Request (Station Transfer Number for SRVCC (STN-SR), Mobile Station International Subscriber Directory Number (MSISDN), Source to Target Transparent Container, Mobility Management (MM) Context) message to the MSC Server. The MSC server is selected based on the Target ID received in the Handover Required message. The MME received STN-SR and MSISDN from the HSS as part of the subscription profile downloaded during the E-UTRAN attach procedure. The MM Context contains security related information. CS security key is derived by the MME from the E-UTRAN/EPS domain key as defined in TS 33.401. The CS Security key is sent in the MM Context.
Step 305. The MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by sending a Prepare Handover Request message to the target MSC.
Step 306. The Target MSC performs resource allocation with the target BSS by exchanging Handover Request/Acknowledge messages.
Step 307. Target MSC sends a Prepare Handover Response message to the MSC Server.
Step 308. The establishment of circuit connection between the target MSC and the Media Gateway (MGW) associated with the MSC Server e.g. using the ISDN User Part (ISUP) Initial Address Message (IAM) and Address Complete Message (ACM) messages.
Step 309. The MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP IAM (STN-SR) message towards the IMS. Standard IMS Service Continuity procedures are applied for execution of the Session Transfer, see TS 23.292 and TS 23.237. During the execution of the Session Transfer procedure the remote end is updated with the Session Description Protocol (SDP) of the CS access leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point.
NOTE 1: If the MSC Server is using an ISUP interface, then the initiation of the session transfer may fail if the subscriber profile including Customized Applications for Mobile networks Enhance Logic (CAMEL) triggers is not available prior handover (see clause 7.3.2.1 in TS 23.292).
Step 310. MSC Server sends a Forward Relocation Response (Target to Source Transparent Container) message to the source MME. Source MME knows that at the end of the PS-CS handover the non-Guaranteed Bit Rate (non-GBR) bearers should be preserved.
Step 311a. Source MME sends a Handover Command (Target to Source Transparent Container) message to the source E-UTRAN. The message includes information about the voice component only.
Step 312. Source E-UTRAN sends a Handover from E-UTRAN Command message to the UE.
Step 313. Handover Detection at the target Base Station Subsystem (BSS).
Step 313a. The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2. This triggers the Target SGSN to send a Suspend Request message to the Source MME. The MME returns a Suspend Response to the Target SGSN, which contains the MM and PDP contexts of the UE. The MME also starts the preservation of non-GBR bearers and the deactivation of the voice bearer.
Step 314. Target BSS sends a Handover Complete message to the target MSC.
Step 315. Target MSC sends a Send End Signal (SES) HO complete message to the MSC Server.
Step 316. Completion of the establishment of the circuit connection between the MSC and the MGW associated with the MSC Server is completed e.g. with the target MSC sending ISUP Answer message to the MSC Server.
Step 317. MSC Server sends a Forward Relocation Complete message to the source MME, informing it that the UE has arrived on the target side. Source MME acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the MSC Server.
Step 318. MSC Server may perform a MAP Update Location to the Home Subscriber Server/Home Location Register (HSS/HLR) if needed. This may be needed for MSC Server to receive GSM Supplementary Service information and routing of mobile terminating calls properly in certain configuration. This Update Location is not initiated by the UE.
After the CS voice call is terminated and if the UE is still in GERAN, then (as specified in TS 23.060) the UE shall resume PS services by sending a Routing Area Update Request message to the SGSN. The Update Type depends on the mode of operation of the GERAN network, e.g. in mode I a Combined RA/LA Update is used and in mode II or III Routing Area Update is used.